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Abstract — Tor,  the  most  popular  deployed  distributed  onion 
routing  network,  suffers  from  performance  and  scalability  prob¬ 
lems  stemming  from  a  lack  of  incentives  for  volunteers  to 
contribute.  Insufficient  capacity  limits  scalability  and  harms  the 
anonymity  of  its  users.  We  introduce  LIRA,  a  lightweight  scheme 
that  creates  performance  incentives  for  users  to  contribute  band¬ 
width  resources  to  the  Tor  network.  LIRA  uses  a  novel  crypto¬ 
graphic  lottery:  winners  may  be  guessed  with  tunable  probability 
by  any  user  or  bought  in  exchange  for  resource  contributions. 
The  traffic  of  those  winning  the  lottery  is  prioritized  through 
Tor.  The  uncertainty  of  whether  a  buyer  or  a  guesser  is  getting 
priority  improves  the  anonymity  of  those  purchasing  winners, 
while  the  performance  Incentives  encourage  contribution.  LIRA 
is  more  lightweight  than  prior  reward  schemes  that  pay  for 
service  and  provides  better  anonymity  than  schemes  that  simply 
give  priority  to  traffic  originating  from  fast  relays.  We  analyze 
lira’s  efficiency,  anonymity,  and  incentives,  present  a  prototype 
implementation,  and  describe  experiments  that  show  it  indeed 
improves  performance  for  those  servicing  the  network. 

I.  Introduction 

Onion  routing  [1],  particularly  as  deployed  in  Tor  [2],  [3] 
is  the  most  widely  used  and  extensively  studied  approach  to 
anonymous  communication.  By  protecting  who  is  talking  to 
whom  and  who  is  accessing  which  networks,  Tor  is  a  desirable 
tool  for  a  variety  of  users.  Its  users  include,  but  are  not 
limited  to:  web  users  concerned  about  privacy;  journalists, 
intelligence  agents,  and  law  enforcement  agents  concerned 
about  hiding  their  operations;  political  activists  concerned 
about  surveillance  from  their  government  or  from  political  op¬ 
ponents;  and  businesses  concerned  about  industrial  espionage 
or  competitive  intelligence. 

Predominantly  designed  to  provide  anonymity  for  its  users. 
Tor  works  by  sending  client  traffic  through  multiple  relays 
after  encrypting  it  once  for  each  relay  in  the  circuit.  Each  relay 
decrypts  and  forwards  traffic  through  the  circuit  as  specified 
by  the  client.  This  traffic  encryption  and  decryption  process 
prevents  a  single  member  of  the  circuit  from  linking  the  user 
to  its  intended  Internet  destination.  As  it  is  paramount  to  Tor’s 
design,  anonymity  has  been  improved  by  other  design  aspects: 
frequently  rotating  circuits  and  selecting  the  first  relay  from 
a  small  set  of  guards  helps  defend  against  passive  logging 
attacks  [4],  [5]  and  further  strengthens  users’  privacy. 
Limited  Capacity  and  Scalability.  Tor  relays  are  run  by 
volunteers  who  altruistically  contribute  bandwidth  and  com¬ 
putational  resources  to  the  network.  As  a  result.  Tor  is  usable 


even  by  those  unable  or  unwilling  to  contribute  because  they, 
e.g.,  have  slow  connections  or  are  behind  restrictive  firewalls. 
Unfortunately,  network  capacity  is  limited  to  these  altruistic 
contributions  and  has  increased  sublinearly  to  Tor’s  popularity. 
In  Tor’s  current  resource  model,  its  popularity  harms  its  us¬ 
ability  and  performance,  and  may  therefore  have  a  significant 
negative  impact  on  its  users’  anonymity  [6],  [7].  The  Tor 
Project  [3]  has  enumerated  many  performance  problems  they 
have  recognized  and  are  actively  pursuing  designs  that  improve 
the  network  in  this  regard  [8].  Recent  work  has  focused 
on  reducing  the  existing  load  on  the  network  [9],  [10]  and 
optimizing  utilization  of  the  existing  resources  [1 1],  [12],  [13], 
but  bolstering  capacity  while  at  the  same  time  encouraging 
scalability  remains  a  challenging  open  problem. 

Various  responses  to  this  capacity  and  scalability  problem 
have  been  considered.  Thus  far  Tor  has  relied  on  community 
support  to  provide  much-needed  boosts  to  its  capacity.  For 
example,  Torservers.net  [14]  is  a  registered  German  non-profit 
organization  that  uses  donations  to  purchase  or  rent  high- 
bandwidth  servers  for  the  public  Tor  network.  Similarly,  the 
Electronic  Frontier  Foundation  ran  a  “Tor  Challenge”  in  which 
they  encouraged  people  to  set  up  relays  and  listed  the  names 
of  those  who  chose  to  be  acknowledged  for  doing  so  [15]. 
Unfortunately,  the  support  is  limited  and  inadequate  for  Tor 
to  scale  to  millions  of  simultaneous  users  while  remaining 
usable.  Currently  Tor  is  initiating  direct  funding  of  relays  using 
government  funding  it  receives  for  this  purpose.  As  noted  in 
the  blogpost  announcement,  this  raises  numerous  questions, 
such  as  the  impact  on  diversity  of  the  infrastructure  [16]. 
Another  unknown  is  the  sustainability  of  any  resulting  capacity 
increase  if  this  direct  funding  ceases. 

A  more  scalable  way  to  increase  capacity  is  to  require  all 
users  to  contribute  in  a  peer-to-peer  fashion.  However,  not 
only  would  it  be  difficult  to  force  users  to  comply,  this  would 
also  turn  away  some  of  those  most  in  need  of  its  protections 
due  to  an  inability  to  contribute.  Further,  combined  with  a 
potential  lack  of  user  interest  in  operating  and  maintaining 
servers,  this  strategy  may  produce  undesirable  low  bandwidth 
or  unstable  relays  that  increase  network  bottlenecks  and  may 
actually  harm  performance  [17]. 

Numerous  proposals  to  recruit  new  relays  using  incentives 
have  appeared  in  the  literature.  Although  the  incentive  ap¬ 
proach  is  promising,  past  designs  have  thus  far  been  plagued 
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with  anonymity  or  efficiency  problems.  Both  the  “gold  star” 
scheme  [18]  and  Tortoise  [9]  have  serious  anonymity  problems 
that  allow  relays’  traffic  to  be  identified,  while  PAR  [19], 
XPAY  [20],  and  BRAIDS  [21]  do  not  not  scale  well  due 
to  inefficient  protocols.  Our  goal  in  this  work  is  to  design 
and  evaluate  a  system  that  combines  strong  anonymity  with 
scalable  efficiency. 

Lightweight  Incentivized  Routing  for  Anonymity.  We 

present  LIRA,  a  unique  and  scalable  approach  to  creating 
incentives  for  users  to  contribute  computational  and  bandwidth 
resources  to  Tor.  Proportionally  differentiated  services  [22] 
are  the  foundation  for  incentives:  users  who  choose  to  run 
relays  will  be  able  to  proportionally  increase  their  performance 
relative  to  those  not  contributing.  Further,  relays  may  con¬ 
tribute  more  resources  to  increase  the  amount  of  their  traffic 
that  gets  prioritized,  leading  to  greater  network  capacity  and 
performance  improvements  for  everyone.  At  the  same  time, 
LIRA  frustrates  the  adversary’s  ability  to  utilize  traffic  priority 
as  a  distinguisher  of  client-initiated  and  relay-initiated  circuits. 

LIRA  produces  incentives  with  a  novel  cryptographic  lottery 
design  together  with  a  new  circuit  scheduling  algorithm  that 
prioritizes  traffic  from  those  winning  the  lottery.  To  play  the 
relay  lotteries,  clients  send  a  ticket  to  each  relay  in  each  circuit 
built  in  LIRA.  Clients  generate  random  number  guesses  to 
produce  tickets  locally,  each  of  which  will  be  a  winner  for 
a  relay  lottery  with  a  tunable  probability.  Relays  contributing 
resources  may  collect  anonymous  coins  proportional  to  their 
contributions,  and  exchange  the  coins  for  guaranteed  winners 
to  relay  lotteries  of  their  choosing.  Relays  differentiate  perfor¬ 
mance  by  prioritizing  traffic  for  winning  circuits. 

LIRA  maintains  anonymity.  An  adversary  in  LIRA  is  un¬ 
able  to  distinguish  relays’  purchased  winners  from  clients’ 
guessed  winners,  whereas  an  adversary  in  the  “gold  star”  [18] 
and  Tortoise  [9]  incentive  designs  can  determine  that  traffic 
initiated  from  relays  with  absolute  certainty.  LIRA  provides 
tunable  anonymity:  increasing  the  probability  that  a  guessed 
ticket  is  a  winner  reduces  the  adversary’s  certainty  about  the 
traffic  source. 

LIRA  is  lightweight.  Previous  schemes  either  require  that 
an  online  trusted  third  party  participates  in  routing  in  order 
to  prevent  double  spending,  as  in  PAR  [19]  and  XPAY  [20], 
or  that  the  third  party  distributes  tickets  to  all  relays  and 
all  clients,  as  in  BRAIDS  [21].  Neither  of  these  approaches 
scales  well  to  millions  of  simultaneous  users.  LIRA  is  scalable 
because  purchased  tickets  are  not  managed  for  clients,  but  only 
for  the  orders  of  magnitude  smaller  set  of  relays,  and  there  is 
no  spending  transaction  when  circuits  are  built. 
Contributions.  This  work’s  major  contributions  may  be  sum¬ 
marized  as  follows: 

•  A  unique  and  novel  cryptographic  lottery  approach  to 
providing  incentives  to  run  Tor  relays  that  combines 
strong  anonymity  with  scalable  efficiency 

•  A  new  Tor  circuit  scheduler  that  produces  performance 
incentives  through  proportional  throughput  differentiation 

•  A  detailed  efficiency,  anonymity,  and  incentive  analysis 
and  comparison  to  BRAIDS  [21],  the  state-of-the-art  Tor 


incentive  design 

•  A  prototype  implementation  and  experimental  validation 
that  LIRA  provides  incentives  to  contribute 
Outline.  The  rest  of  the  paper  is  outlined  as  follows.  Section  II 
provides  details  about  the  network,  our  threat  model,  and  our 
objectives.  LIRA’S  technical  design  is  given  in  Section  III, 
while  Section  IV  analyzes  LIRA’S  efficiency,  anonymity,  and 
incentives.  Our  protoype  and  experimental  evaluation  are 
described  in  Section  V,  Section  VI  discusses  related  work, 
and  Section  VII  concludes. 

11.  Preliminaries 

We  now  discuss  specific  details  about  the  deployed  Tor 
network  that  LIRA’S  design  considers  and  describe  the  circuit 
building  protocol  to  facilitate  an  understanding  of  how  we 
will  propose  to  modify  it.  We  also  introduce  a  bank  as  an 
additional  service  that  will  be  utilized  in  LIRA’S  design, 
specify  our  adversarial  threat  model,  and  clarify  the  objectives 
of  our  system.  Though  LIRA  could  be  applied  to  various 
anonymous  communication  systems,  our  exposition  will  focus 
on  the  Tor  [2]  onion  routing  network. 

Onion-Routing  Network.  The  most  popular  instantiation  of 
onion  routing  [1],  the  Tor  overlay  network  includes  a  directory 
service  that  publishes  information  about  the  available  relays. 
Using  the  directory  information,  clients  build  three-hop  cir¬ 
cuits  that  begin  with  one  of  a  small  set  of  entry  guard  relays 
and  end  with  an  exit  relay  willing  to  connect  to  the  client’s 
desired  Internet  service.  A  circuit  is  built  through  a  telescoping 
process:  an  encrypted  tunnel  is  first  created  to  an  entry  guard, 
after  which  the  tunnel  is  extended  one  relay  at  a  time  until  the 
circuit  is  completely  established  at  the  exit  relay.  During  this 
building  process,  the  client  negotiates  an  ephemeral  key  with 
each  relay  in  the  circuit  using  a  Diffie-Hellman  key  exchange 
protocol.  Once  established,  client  TCP  streams  that  conform  to 
the  exit  relay’s  exit  policy  may  be  multiplexed  over  the  circuit 
for  ten  minutes,  after  which  the  circuit  will  be  marked  as 
dirty  and  will  not  permit  any  new  application  connections.  The 
circuit  is  destroyed  once  existing  application  connections  are 
done  using  it.  All  data  transferred  over  the  circuit  is  packaged 
into  uniform-sized  cells  and  encrypted  using  the  negotiated 
ephemeral  keys. 

A  relay  may  be  servicing  several  circuits  at  any  given 
time.  Every  circuit  that  results  in  data  exchange  between 
any  pair  of  relays  is  multiplexed  over  a  single  TCP  onion¬ 
routing  connection  between  the  pair.  Cells  read  from  this 
connection  are  processed  and  placed  in  a  scheduling  queue 
before  being  switched  onto  the  corresponding  outgoing  onion¬ 
routing  connection  to  the  next-hop  relay. 

Roughly  3000  geographically  diverse  Tor  relays  currently 
transfer  a  combined  total  of  about  1700  MiB/s  from  an  esti¬ 
mated  400,000  unique  users  per  day  [23].  We  parameterize  the 
onion-routing  network  size  for  design  and  analysis  purposes 
as  m  onion  routers  and  n  unique  users  in  a  given  time 
period.  We  also  assume  the  existence  of  a  new  bank  service 
B.  The  bank  will  assist  both  in  establishing  valid  lotteries 
with  the  relays  and  in  assessing  and  rewarding  contributions 


Fig.  1;  An  overview  of  LIRA’S  design,  (a)  Relays  coordinate  with  the  bank  to  learn  which  tickets  will  be  winners  for  their  lottery, 
(b)  Relays  accumulate  anonymous  coins  by  contributing  bandwidth  to  Tor,  and  may  exchange  them  for  guaranteed  winners 
to  other  relay  lotteries,  (c)  Clients  send  either  guaranteed  winners  or  guesses  through  their  circuits.  Relays  proportionally 
differentiate  throughput  by  prioritizing  circuits  that  submitted  winners  to  every  circuit  position. 


(see  Section  III).  We  will  assume  that  all  entities  can  use 
the  underlying  communication  network  to  send  each  other 
messages  directly. 

Adversary.  We  will  consider  the  actions  of  both  a  malicious 
network  adversary  and  an  honest-but-curious  {i.e.  passive) 
bank.  We  use  the  standard  network  adversary  for  onion  rout¬ 
ing  [24],  which  is  local  in  that  he  can  observe  part  of  the 
network,  is  active  in  that  he  can  perform  computations,  send 
messages,  run  onion  routers,  and  act  as  a  client.  Although  in 
this  paper  we  model  the  bank  as  a  single  entity,  we  expect 
the  ultimate  implementation  of  the  bank  to  be  similar  to  that 
of  the  directory  service  in  the  current  public  Tor  network; 
multiple  entities  run  the  service  and  form  a  consensus  on  the 
authoritative  documents.  Therefore,  we  assume  that  the  bank 
faithfully  executes  the  protocol  and  only  makes  observations 
that  are  part  of  that  protocol.  In  particular,  he  does  not  act  as 
an  onion  router  or  as  a  client,  only  observes  messages  that  are 
sent  to  him,  and  does  not  collude  with  the  network  adversary. 
Objectives.  Our  goal  is  to  provide  incentive  for  anonymous- 
network  users  to  run  relays  while  preserving  the  desirable 
features  of  onion  routing.  Therefore,  we  will  evaluate  LIRA 
in  terms  of  its  functionality,  its  efficiency,  the  anonymity  it 
provides,  and  the  incentive  it  offers  to  run  a  relay. 

We  require  that  our  system  provide  the  functionality  pro¬ 
vided  by  onion  routing.  In  particular,  it  should  provide  bidirec¬ 
tional,  stream-oriented,  low-latency  communication  between 
pairs  of  users.  In  addition,  the  responder  of  a  stream  should 
only  need  to  run  a  standard  transport  protocol  so  users  can 
communicate  with  destinations  that  aren’t  aware  of  or  designed 
for  anonymous  communication  protocols. 

We  also  require  that  the  efficiency  of  our  system  is  com¬ 
parable  to  onion  routing.  The  success  of  Tor  over  alternative 
anonymous-communication  protocols  can  be  attributed  in  large 
part  to  its  relatively  low  computational  and  communication 
costs.  In  particular,  our  protocol  should  have  costs  for  each 
user  that  are  proportional  to  amount  of  his  anonymized  traffic 
and  for  relays  as  a  group  that  are  proportional  to  the  total 
amount  of  anonymized  traffic.  Moreover,  we  want  the  resource 
requirements  at  the  bank  to  be  achievable  under  current  Tor 


network  conditions  and  to  scale  well  with  a  growing  network. 

Our  evaluation  will  consider  relationship  anonymity  [24] 
in  our  system,  that  is,  the  extent  to  which  users  can  be 
linked  to  their  communication  partners.  We  will  measure  this 
using  the  probability  that  an  adversary  assigns  to  a  user 
communicating  with  his  actual  destinations.  We  will  also 
evaluate  the  incentives  provided  by  LIRA.  As  it  is  designed 
to  improve  throughput  and  latency  for  users  running  relays, 
we  will  measure  this  performance  difference  while  also  con¬ 
sidering  the  extent  to  which  a  user  can  cheat  and  obtain  these 
improvements  without  contributing. 

III.  Design 

To  achieve  the  objectives  stated  in  Section  II,  LIRA  em¬ 
ployes  a  cryptographic  lottery  and  a  relay  circuit  scheduler  that 
prioritizes  traffic  for  users  who  submit  winning  lottery  tickets. 
A  high  level  overview  of  LIRA’S  design  and  the  interactions 
between  these  mechanisms  is  given  in  Figure  1 .  Through  coor¬ 
dination  with  the  bank,  the  relays  receive  information  allowing 
them  to  recognize  winning  tickets  to  their  own  lottery  (see  Fig¬ 
ure  la).  Over  time,  relays  accumulate  anonymous  electronic 
coins  from  the  bank  by  providing  service  to  the  network.  These 
coins  may  be  exchanged  for  guaranteed  winning  ticket  values 
for  a  variety  of  relay  lotteries  (see  Figure  lb).  Clients  without 
coins  guess  ticket  values  to  produce  them  locally:  their  guesses 
will  be  winners  with  tunable  probability.  Tickets  are  passed 
to  the  relays  through  circuit  control  messages,  and  relays 
cannot  distinguish  a  guessed  winner  from  a  guaranteed  winner. 
Relays  in  every  circuit  position  verify  tickets  and  prioritize 
circuits  of  submitted  winners  by  proportionally  increasing  their 
throughput  (see  Figure  Ic).  We  now  describe  LIRA’S  design 
in  further  detail. 

A.  Setup 

The  bank  will  use  RSA  blind  signatures  [25],  which  allow 
it  to  sign  a  message  without  being  able  to  link  the  signature 
with  an  earlier  signing  request.  Let  M  be  the  RSA  modulus 
of  the  bank,  e  be  the  public  encryption  exponent,  and  d  be 
the  corresponding  private  decryption  exponent.  Each  relay  r 


will  need  a  public  random  value  Xr  €  associated  with  it. 
These  values  can  be  generated  by  the  bank  and  distributed  by 
the  directory  service.  For  each  relay  r,  the  bank  computes  its 
signature  xf  and  sends  it  to  r.  Finally,  the  system  will  use  a 
full-domain  hash  function  H  :  {0, 1}*  — >  {0, where  A 
denotes  the  security  parameter  for  the  system.  We  can  use  a 
cryptographic  hash  function  such  as  SHA-1  for  H. 

B.  Coin  Distribution 

LIRA  rewards  relays  proportional  to  the  amount  of  band¬ 
width  they  contribute.  Since  relays  can  not  be  trusted  to 
self-report  their  bandwidth  contributions,  we  determine  each 
relay’s  contribution  with  a  secure  bandwidth  measurement 
scheme  such  as  EigenSpeed  [26].  Using  EigenSpeed,  relays 
opportunistically  measure  and  evaluate  each  other’s  contribu¬ 
tions  to  form  an  accurate  consenus  of  relay  bandwidth  that 
has  been  shown  to  be  resistant  to  attacks  by  malicious  groups 
of  colluding  nodes  [17],  [26].  The  measurement  process  runs 
continuously  while  a  consensus  is  formed  periodically.' 

The  bank  stores  and  tracks  each  relay’s  bandwidth  contri¬ 
bution  over  time,  keeping  an  account  balance  of  contributed 
bytes  and  updating  it  with  each  new  bandwidth  contribution 
consensus.  A  relay  may  collect  i  digital  coins  from  the  bank 
for  every  a  bytes  it  has  contributed,  where  i  is  the  circuit 
length  (£  =  3  in  Tor).  A  coin  is  constructed  using  a  blind 
signature  [25]  to  prevent  the  bank  from  later  linking  the  coin 
to  a  given  relay  (the  final  signature  is  unknown  to  the  bank). 

Relays  use  their  coins  to  purchase  guaranteed  winners  from 
the  bank  (see  Section  III-C).  The  bank  prevents  double  spend¬ 
ing  of  these  by  keeping  a  database  of  previously  spent  coins 
that  it  checks  (and  possibly  updates)  when  it  receives  coins 
in  a  purchase  request.  The  size  of  the  database  is  bounded  by 
a  coin  expiration  period  77.  A  blind  signature  simplifies  the 
construction  of  the  coin  over  some  electronic  cash  schemes 
since  we  do  not  require  double  spending  detection  by  a  third 
party  after  a  coin  has  been  successfully  spent. 

Advantages  of  using  coins  in  the  manner  outlined  above  in¬ 
clude  flexibility  and  transferability.  Coins  xre  flexible  because 
relays  may  accumulate  them  during  periods  when  they  are  not 
actively  using  Tor  as  a  client,  and  they  are  valid  as  long  as  the 
bank  exists  and  the  coin  has  not  expired.  The  expiration  period 
f]  is  set  so  that  the  bank  can  store  and  access  a  list  of  spent, 
unexpired  coins  and  may  be  adjusted  as  the  Tor  network  scales. 
Section  IV  shows  that  currently  in  Tor  127.5  coins  would  be 
generated  per  second.  If  each  coin  is  a  1024-bit  signature,  we 
can  set  rj  =  28  days,  resulting  in  list  of  at  most  4.60  GiB  and 
fitting  into  a  single  machine’s  memory. 

A  coin  is  inherently  transferable  because  it  is  not  tied  to  a 
specific  relay,  allowing  the  possibility  of  a  secondary  economy 
to  form  around  the  purchase  and  sale  of  coins.  In  such  an 
economy,  it  would  also  be  possible  for  clients  who  do  not  run 
relays  to  obtain  coins,  improving  anonymity  by  increasing  the 
uncertainty  of  the  sources  of  winning  tickets. 

*Tor  currently  computes  the  directory  consensus  every  hour,  which  could 
be  amended  to  include  the  bandwidth  contribution  information. 


We  configure  the  ratio  of  the  number  of  contributed  bytes 
a  to  the  number  of  prioritized  bytes  /?  received  in  return  to 
a  =  {£+  1)  ■  p.  By  requiring  a  contribution  £  +  1  times  that 
of  prioritized  consumption,  we  account  for  transferring  data 
through  each  of  the  I  relays  in  the  circuit,  and  also  ensure  that 
new  relays  that  join  Tor  will  only  increase  its  overall  capacity. 

C.  Purchasing  Guaranteed  Winners 

Relays  will  prioritize  traffic  on  circuits  for  which  winning 
lottery  tickets  are  supplied.  Winners  will  be  determined  using 
a  relay-specific  permutation  that  we  define  below  (Eq.  2).  Let 
the  size  of  the  permutation’s  input  space  be  2^,  and  let  gr  : 
[2^]  — >■  [2^]  be  the  permutation  of  relay  r.  A  value  x  is  a 
winner  for  r  if,  for  yo\\yi  =  gr{x),  j/o  ®  ?/i  <  p‘2-^^^,  where 
p  €  [0, 1]  is  a  system  parameter.  Thus  a  client  that  guesses 
an  input  x  randomly  will  obtain  a  winner  with  probability  p. 
To  guarantee  priority,  a  client  can  also  use  coins  earned  by 
providing  service  to  the  network  to  purchase  winners. 

Setting  p  presents  a  tradeoff  between  anonymity  and  incen¬ 
tives.  Guessing  a  winner  is  less  likely  for  smaller  values  of  p. 
In  this  case,  prioritized  circuits  are  more  likely  to  be  paid  for 
and  thus  probably  originate  at  a  client  also  running  a  relay. 
Eor  larger  values  of  p,  it  is  more  likely  that  a  circuit  will  be 
prioritized  by  chance,  and  there  will  be  less  reason  to  run  a 
relay  and  earn  priority.  (We  discuss  this  tradeoff  in  more  detail 
in  Section  IV.)  We  adopt  a  setting  of  p  =  Eor  the 

current  Tor  network,  we  estimate  n  to  be  10000,  and  thus  we 
would  set  p  =  10“^/^  «  0.22. 

The  construction  of  the  permutations  gr  is  designed  to 
provide  properties  similar  to  those  of  a  pseudorandom  permu¬ 
tation  (PRP),  although  they  are  technically  somewhat  different. 
In  particular,  the  permutations  will  appear  sufficiently  random 
to  clients  that  they  cannot  produce  winners  with  probability 
significantly  greater  than  p.  Moreover,  they  are  efficiently 
invertible  so  that  the  bank  can  sell  winners  by  choosing 
V  =  J/o||j/i  such  that  j/o  ©  Pi  <  p2?'l'^  and  providing  the 
corresponding  input  The  construction  also  allows  the 

purchase  of  winners  for  r  to  be  made  while  hiding  the  identity 
of  r  and  the  winning  number  from  the  bank. 

If  we  didn’t  want  to  hide  this  information  from  the  bank,  we 
could  easily  implement  the  rest  of  this  functionality  by  using  a 
PRP  such  as  AES.  The  bank  could  share  different  private  keys 
with  each  of  the  relays,  and  the  user  would  simply  purchase  a 
winner  by  presenting  a  coin  and  specifying  a  relay.  We  wish 
to  keep  the  bank  as  oblivious  as  possible,  and  thus  we  use  a 
more  involved  construction  for  the  lottery  permutations. 

The  essential  ingredient  of  the  construction  is  for  the  bank 
to  use  blind  signatures  to  obliviously  provide  a  relay-specific 
input  to  a  certain  pseudorandom  function  (PRE)  (Eq.  1).  We 
then  use  a  two-round  version  of  the  Luby-Rackoff  construc¬ 
tion  [27]  to  convert  the  PRE  into  a  permutation  that  is  largely 
unpredictable  to  the  relay. 

1)  Private  Evaluation  of  Pseudorandom  Functions:  The 
PRE  we  use  is  adapted  from  one  suggested  by  De  Cristofaro  et 


1.  c  obtains  blinded  signature  bxf 
either  from  B  or  as  protocol  input. 

2.  c  sends  bH{x)xf  to  B. 

3.  B  sends  H{H{x)xf)  to  c. 

4.  c  outputs  H{xH{H{x)xf). 

Fig.  2;  PRF  Protocol:  c  obtains  fr{x)  from  B 

al.  [28]  that  can  be  computed  obliviously.^  Our  construction 
doesn’t  provide  full  obliviousness  with  respect  to  the  bank, 
but  it  will  provide  privacy  assuming  that  the  bank  does  not 
collude  with  a  relay.  The  PRF  used  by  relay  r  is 

frix)  =  H{x{H{H{x)xf))),  (1) 

where,  as  described  above,  x^  G  Z’^  is  publicly  known. 

The  PRF  Protocol  for  client  c  to  obtain  fr{x)  from  the  bank 
B  is  given  in  Figure  2.  We  leave  the  option  to  obtain  a  blind 
signature  in  Step  1  as  an  input  to  the  protocol  to  enable  a 
batch-mode  execution  that  will  be  used  in  the  final  purchase 
protocol.  The  client  will  be  unable  to  guess  outputs  that  he 
doesn’t  query  with  better  than  random  chance  because  the 
relay  signature  xf  never  appears  in  a  message  from  the  server 
that  hasn’t  been  blinded  or  hashed.  Moreover,  the  protocol 
protects  the  privacy  of  the  client’s  inputs  (doing  so  is  what 
prevents  us  from  using  a  simpler  PRF,  such  as  H{xfx)).  In 
particular,  the  first  unblinded  input  the  bank  sees  has  a  factor 
H{x)  and  thus  appears  random  given  that  the  bank  doesn’t 
know  X.  Including  a  factor  of  x  before  applying  H  in  the  last 
step  prevents  the  bank  itself  from  learning  the  final  output. 

2 )  Private  Permutation  Evaluation:  Now  we  consider  how 
to  turn  this  into  a  permutation.  Given  /  :  {0, 1}^'  — {0, 1}^, 
the  Feistel  permutation  Dj  :  {0,1}^^  — >  {0,1}^^  on  a;  = 
a:i||a:o,  Xi,Xq  G  {0,1}^,  is  defined  as 

Df{xi\\xQ)  =  (a:o||a:i  0  f{xo)). 

This  is  invertible  because  xq  is  contained  in  the  first  k  bits, 
and  xi  can  be  calculated  as  f{xo)  0  {xi  0  f{xo)).  Luby  and 
Rackoff  showed  that  applying  the  Feistel  permutation  four 
times  with  four  pseudorandom  functions  yields  a  pseudoran¬ 
dom  permutation.  We  use  this  idea,  but,  in  our  setting,  we 
will  disallow  winners  at  a  relay  that  result  in  PRF  inputs  that 
have  been  used  before.  Thus,  we  can  use  the  Luby-Rackoff 
construction  with  the  single  pseudorandom  function  fr-  In 
addition,  we  do  not  need  the  permutation  output  to  appear 
random,  but  rather  the  XOR  of  the  output  halves.  Thus,  we 
are  able  to  reduce  the  number  of  Feistel  permutations  to  two. 
We  therefore  obtain  a  permutation  for  relay  r  of 

9r{x)  =  Df^{Df^{x)) .  (2) 

The  permutation  in  Equation  2  is  used  by  the  relay  to 
determine  if  a  given  ticket  is  a  winner.  To  purchase  a  winner, 

^The  PRF  they  suggest  is  To  compute  it,  the  client  computes 

H(x),  obtains  an  RS A  blind  signature  on  it  from  the  bank,  and  applies  H' 
to  the  result. 


1.  c  randomly  chooses  a  and  sends  a^Xr  to  B. 

2.  B  randomly  chooses  b  and  sends  feaccj?  to  c. 

3.  c  uses  the  PRF  Protocol  with  input  bxf 

to  obtain  friyi)  and  sets  y2  =  fr{yi)  0  yo- 

4.  c  uses  the  PRF  Protocol  with  input  bxf 

to  obtain  fr{y2)  and  sets  ys  =  fr{y2)  0  yi- 

5.  c  outputs  2/3 II J/2- 

Fig.  3:  Permutation  Protocol:  c  obtains  g~^{y)  from  B 


1 .  c  pays  B  a  digital  coin. 

2.  c  randomly  chooses  yo,yi  such  that 
2/0  ®  2/1  < 

3.  c  uses  the  Permutation  Protocol  to 
obtain  g~^{yo\\yi)- 

Fig.  4:  Winner  Purchase  Protocol:  c  purchases  a  winner  for  r 
from  B 


a  client  will  actually  choose  a  winning  permutation  output 
and  apply  the  inverse  permutation  to  obtain  the  ticket  number. 
Let  such  an  output  he  y  —  yi\\yo,  yo,yi  S  {0,1}^/^.  The 
Permutation  Protocol  for  a  client  c  to  obtain  g~^{y)  from  the 
bank  B  is  given  in  Figure  3.  Observe  that  this  protocol  gives 
the  client  quite  a  bit  more  information  about  the  function  (/“^ 
than  a  simple  oracle  query  would.  In  fact,  it  reveals  enough 
information  for  the  client  to  determine  values  of  g  which 
he  has  not  obtained  via  the  protocol.  However,  this  is  only 
possible  for  a  negligible  quantity  of  inputs  and  we  will  show 
that  relays  can  limit  him  to  obtaining  guaranteed  priority  only 
as  many  times  as  he  has  paid  for  winners  (see  Section  IV). 

3)  Protocol  to  Purchase  Winners:  The  Winner  Purchase 
Protocol  run  by  client  c  to  purchase  a  winner  for  relay  r 
from  the  bank  B  is  given  in  Figure  4.  We  emphasize  that  the 
bank  will  only  participate  in  step  3  of  the  Winner  Purchase 
Protocol  if  c  presents  a  valid  coin.  This  protocol  is  run  entirely 
over  an  anonymous  onion-routing  connection  made  by  c  to  B. 
To  prevent  the  bank  from  learning  when  encrypted  circuits 
were  made,  clients  should  buy  enough  winners  at  a  time 
to  construct  7  prioritized  circuits,  should  maintain  a  reserve 
of  enough  winners  to  construct  7/2  prioritized  circuits,  and 
after  depleting  their  reserve  below  this  amount  should  wait  a 
minimum  time  selected  uniformly  at  random  from  [0,  w]  before 
purchasing  more  winners. 

We  set  7  to  balance  privacy  with  respect  to  the  bank  with 
the  flexibility  of  the  recommended  buying  strategy.  Increasing 
7  increases  the  amount  of  time  between  batches  of  purchases 
observed  by  the  bank  and  thus  the  number  of  other  users’ 
prioritized  circuits  that  hide  the  buyer’s  circuits.  On  the  other 
hand,  decreasing  7  decreases  the  number  of  coins  a  relay 
should  have  stockpiled  before  purchasing  winners.  We  will  ask 
a  relay  to  run  for  at  least  3  hours  before  purchasing  winners. 
For  a  relay  providing  the  current  median  bandwidth  in  Tor  of 
100  KiB/s  [23]  and  with  Tor’s  path  length  of  £  =  3,  after  3 
hours  the  relay  obtains  about  79  coins.  Each  prioritized  circuit 


1.  c  runs  onion-routing  circuit-creation  protocol. 

2.  For  each  relay  r  in  the  circuit,  c  sends  a  TICKET 
cell  with  either  a  purchased  winner  Wr 

or  random  guess  Xr  S  [1,2^]. 

3.  For  every  /3  bytes  that  pass  over  the  circuit, 

c  repeats  Step  2  with  new  winners  or  guesses. 

Fig.  5:  Circuit  Setup  Protocol  for  client  c 

costs  I  coins,  and  so  we  set  7  =  26. 

We  set  uj  to  maximize  the  number  of  prioritized  connections 
that  could  have  triggered  a  purchase  without  emptying  the 
reserve  of  winners.  Thus  we  set  uj  to  the  point  at  which 
a  client’s  reserve  of  7/2  winners  would  become  empty  had 
he  been  making  only  prioritized  connections.  For  clients  that 
make  new  circuits  at  rate  r  this  happens  at  w  =  7/(2r).  In 
Tor,  r  «  1,  and  so  we  have  w  =  13  minutes. 

D.  Circuit  Setup 

LIRA  slightly  modihes  the  onion-routing  circuit-creation 
protocol  (cf.  Section  II)  to  accommodate  prioritization.  Clients 
use  a  new  TICKET  cell  type  to  send  a  lottery  number  to  each 
relay  on  a  circuit  and  attempt  to  obtain  priority.  A  TICKET  cell 
has  the  structure  [TICKET,  number],  where  the  number  held 
contains  a  value  in  [0,  2^).  This  cell  is  sent  to  a  relay  from  the 
client  over  the  circuit  and  is  thus  onion-encrypted.  In  addition, 
relays  on  a  circuit  signal  prioritization  status  to  one  another. 
These  messages  are  sent  directly  over  an  encrypted  pairwise 
connection  (e.g.  over  the  persistent  TLS  connections  that  Tor 
maintains  between  pairs  of  relays)  with  an  identiher  indicating 
to  which  circuit  they  pertain. 

The  Circuit  Setup  Protocol  at  the  client  is  described  in 
Figure  5.  It  simply  adds  periodic  lottery-ticket  messages  to  the 
standard  circuit-creation  protocol  in  onion  routing.  Note  that 
the  ticket  messages  are  sent  onion-encrypted  over  the  circuit 
and  thus  can  only  be  read  by  the  recipient. 

Relays  determine  priority  for  their  circuits  using  the  Circuit 
Priority  Protocol  described  in  Figure  6.  For  each  position  in 
a  circuit,  a  relay  maintains  priority  values  for  itself,  for  the 
preceding  segment  of  the  circuit,  for  the  succeeding  segment  of 
the  circuit,  and  for  the  entire  circuit.  The  relay  also  maintains 
a  counter  for  the  number  of  priority  bytes  that  are  left  under 
the  current  prioritization.  Observe  that  the  protocol  involves 
explicit  signaling  along  the  circuit  to  synchronize  the  priority 
status  of  the  relays.  Thus,  for  the  circuit  depicted  at  the  bottom 
of  Figure  Ic,  even  though  the  middle  relay  has  received  a 
winner,  it  will  mark  the  circuit  as  DEAD  after  it  receives  a 
DEAD  relay  priority  from  either  the  guard  or  exit  relay. 

Also  observe  that,  during  the  validation  of  a  ticket  number, 
the  PRF  inputs  used  during  the  two  applications  of  the  Feistel 
permutation  (Eq.  2)  are  stored.  If  a  PRF  input  used  during 
ticket  validation  has  been  seen  before,  then  that  ticket  is 
considered  a  loser.  This  prevents  a  client  from  reusing  old 
winners  and  from  using  PRF  outputs  obtained  from  the  bank 
to  construct  multiple  winners.  Finally,  note  that  once  a  losing 


Upon  receiving  data  cell 

If  priority  bytes  counter  is  greater  than  zero 
Reduce  priority  bytes  counter  by  cell  size 
If  priority  bytes  counter  is  zero 

and  self  priority  status  is  not  DEAD 
Set  self  priority  status  to  EXPIRED 
Set  circuit  priority  status  to  EXPIRED. 

Upon  receiving  priority  status  from  adjacent  relay 
Store  status  and  send  to  other  adjacent  relay 
If  all  stored  relay  priorities  are  TRUE 
Set  circuit  priority  TRUE 
If  any  stored  relay  priority  is  DEAD 
Set  circuit  priority  DEAD 
Upon  receiving  TICKET  cell  with  value  x 
Compute  J/0II2/1  =  9r{x),  storing  intermediate 
PRF  inputs 
If  J/o  ®  2/1  <  p2^/2 

and  intermediate  PRF  inputs  previously  unseen 
and  no  stored  priority  status  is  DEAD 
Set  self  priority  status  to  TRUE 
Increment  priority  bytes  counter  by  /3 
Set  circuit  priority  TRUE 

Else  set  self  and  circuit  priority  statuses  to  DEAD 
Send  self  priority  status  to  adjacent  relays 

Fig.  6:  Circuit  Priority  Protocol  for  relay  r 


ticket  has  been  observed,  the  priority  status  is  DEAD  and  no 
further  priority  is  possible  on  the  circuit. 

The  value  of  /3,  the  number  of  bytes  for  which  a  winner 
provides  priority,  provides  a  tradeoff  between  user  anonymity 
and  the  incentive  to  run  a  relay.  A  small  j3  makes  it  unlikely 
that  a  guesser,  that  is,  a  user  who  does  not  buy  winners,  will 
maintain  priority  over  the  life  of  a  typical  circuit.  This  reduces 
the  anonymity  of  a  buyer,  who  we  wish  to  allow  to  obtain 
priority  for  an  entire  connection.  Setting  a  large  /3,  assuming 
the  price  of  a  winning  ticket  increases  proportionally,  causes 
buyers  to  either  use  a  circuit  for  a  long  time,  reducing  their 
anonymity  by  increasing  the  linkability  of  their  connections, 
or  to  lose  many  of  the  bytes  for  which  priority  has  been 
purchased,  decreasing  the  incentive  to  earn  it.  In  addition, 
a  large  /3  increases  the  granularity  of  buying  winners,  and 
so  more  e-cash  must  be  earned  before  it  can  be  used,  again 
decreasing  the  incentive  to  earn  e-cash. 

Given  these  considerations,  we  use  a  value  of  /?  that  is 
greater  than  the  length  of  a  typical  connection.  As  discovered 
by  McCoy  et  al.  [29],  over  90%  of  connections  over  Tor 
are  HTTP  connections.  Ramachandran[30]  shows  data  from 
billions  of  web  pages  showing  that  the  mean  size,  including 
all  embedded  content,  is  320KB.  Cheng  et  al.  [31]  show 
that  the  mean  YouTube  hie  size  is  8.4MB.  To  enable  most 
web  connections  as  well  as  such  popular  activities  as  viewing 
videos,  we  use  /3  =  lOMiB. 


TABLE  I:  Bank  Costs 


E.  Circuit  Scheduling 

To  improve  the  quality  of  service  of  qualifying  traffic — cells 
on  circuits  for  which  valid  winners  have  been  provided — we 
incorporate  ideas  from  the  differentiated  services  architecture 
(DiffServ)  [32].  More  specifically,  we  ensure  a  relative  quality 
ordering  between  qualifying  and  non-qualifying  traffic  using 
a  priority  scheduling  mechanism  based  on  the  proportional 
differentiation  model  [22].  The  model  aims  to  provide  pre¬ 
dictable  and  controllable  performance:  quality  metrics  should 
be  consistently  proportional  between  classes  and  the  propor¬ 
tions  should  be  adjustable. 

In  the  proportional  differentiation  model,  traffic  is  separated 
into  N  classes  labeled  Ci, . . .  ,C7v-  The  model  states  that  the 
desired  quality  measurement  qi  for  each  class  Ci  should  be 
proportional  to  the  other  classes,  where  the  proportions  are 
conhgured  with  a  differentation  parameter  pi  for  each  class. 
The  classes  should  be  scheduled  such  that  the  relative  quality 
of  each  class  follow  the  conhgured  differentation  parameters: 

«  e  liVl.V;  e  (iV|  .  =  « 

where  pi  <  p2  <  ■  ■  ■  <  Pn,  and  a  is  the  measurement 
timescale.  Dovrolis  et  al.  explore  Proportional  Delay  Differ¬ 
entiation  and  a  priority  scheduler  that  differentiates  classes 
using  queueing  delay  (packet  waiting  time)  as  the  desired 
quality  metric  [33].  The  scheduler  utilizes  two  statistics  to 
determine  which  class  Ci  to  schedule  at  time  t:  the  queueing 
delay  Di{t)  of  the  longest  waiting  packet  in  Ci,  and  the  long¬ 
term  average  delay  5i{t)  of  all  previously  scheduled  packets 
(i.e.,  the  average  queueing  delay  of  packets  at  the  moment  they 
are  scheduled).  The  quality  metric  under  Proportional  Delay 
Differentiation  becomes: 


qi{t)  =  D,{t)  ■  /  -f  5i{t)  •(!-/) 

where  /  is  an  adjustable  fraction  (0.875  is  suggested  in  [33]). 
A  priority  is  computed  for  each  Ci  as  Pi{t)  =  qi{t)/pi{t),  and 
the  longest  waiting  packet  from  the  class  with  the  maximum 
computed  priority  is  scheduled  next. 

Once  a  class  is  selected,  the  above  approach  is  essentially 
first-come,  hrst-served  scheduling  since  each  packet’s  delay 
timer  starts  when  the  packet  enters  the  queue.  However,  it 
has  been  shown  that  an  alternative  approach  is  better  suited 
to  scheduling  in  the  Tor  network.  In  particular,  prioritizing 
circuits  with  a  low  exponentially-weighted  moving  average 
(EWMA)  circuit  throughput  may  improve  performance  of 
bursty  traffic  while  minimally  harming  bulk  traffic  with  higher 
desired  long-term  throughput  [11].  Therefore,  LIRA  schedules 
using  Proportional  Throughput  Differentiation,  where  we  ad¬ 
just  the  quality  metric  at  time  t  using  the  EWMA  throughput  of 
the  lowest  throughput  circuit  Ti(t)  and  the  long-term  average 
throughput  Ti{t)  of  previously  scheduled  circuits: 

qt{t)  =  Ti{t)  ■  f  n{t)  •(!-/) 

where  /  remains  adjustable.  The  priority  is  now  computed 
for  each  Ci  as  Pi{t)  =  qi{t)  ■  Pi{t),  and  the  circuit  with  the 
lowest  EWMA  throughput  from  the  class  with  the  minimum 
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computed  priority  is  scheduled  next.  Scheduling  in  this  model 
allows  us  to  configure  the  performance  payoff  associated  with 
running  a  relay,  or  correctly  guessing  a  winning  ticket. 

IV.  Analysis 

A.  Efficiency 

LIRA  preserves  all  the  communication  functionality  of 
onion  routing  while  providing  both  anonymity  and  efficiency. 
This  section  will  consider  how  LIRA  affects  the  overall 
computational  and  communication  costs  of  the  network. 
Overhead.  Clients  may  purchase  a  winner  from  the  bank  for 
each  relay  in  a  circuit  to  receive  /3  =  10  MiB  of  prioritized 
traffic.  Purchasing  these  winners  involves  i  RSA  encryptions 
for  the  client  portions  of  blind  signatures  and  4£  hashes.  This 
cost  is  on  the  order  of  the  cost  for  building  a  circuit,  which  is 
continuously  incurred  throughout  a  Tor  client  session.  Clients 
that  do  not  purchase  winners  incur  no  extra  computational  cost 
by  using  LIRA. 

Our  goal  is  to  keep  relay  CPU  costs  low  because,  according 
to  the  Tor  developers,  the  high-bandwidth  Tor  relays  are 
CPU-bound.  LIRA  introduces  some  overhead  for  relays  with 
ticket  verification,  i.e.,  checking  whether  or  not  tickets  are 
winners.  This  process  involves  evaluating  the  permutation 
in  Equation  2  for  every  bytes  of  transferred  data.  Each 
evaluation  involves  6  hash  computations,  as  well  as  a  smaller 
number  of  multiplications  and  XORs.  The  DiffServ  scheduler 
has  been  shown  to  be  efficient  [33]  since  each  scheduling 
decision  must  only  compute  one  priority  for  each  class. 

The  bank  is  involved  in  distributing  e-cash  to  relays  and 
selling  winning  tickets.  To  generate  e-cash,  the  bank  creates 
a  coin  for  every  a|^  =  10{£  -\-  l)/£  MiB  sent  by  a  given 
relay.  Creating  a  coin  involves  a  single  blind  signature,  and 
these  coins  are  given  to  the  relays  using  a  simple  two-message 
protocol.  To  sell  a  winner,  the  bank  must  verify  a  coin  by 
verifying  a  signature,  provide  a  blind  signature,  and  then 
participate  in  the  batch  PRF  Protocol  two  times,  each  of  which 
involves  one  hash. 

We  now  consider  the  bank  costs  if  the  entire  network  is 
transferring  b  MiB/s  and  the  fraction  of  coins  that  end  up  being 
used  by  the  relays  that  earn  them  is  /.  Let  p  =  £b/{10{i  -\- 
1))  be  the  rate  at  which  coins  are  generated  in  this  network. 
The  rate  of  costly  cryptographic  operations  and  communicated 
messages  for  each  bank  service  are  outlined  in  Table  1.  It 
shows  that  the  rate  of  the  cryptographic  operations  is  just  a 
fraction  of  the  total  rate  of  traffic  on  the  network.  Table  I  also 
shows  that  the  communication  costs  at  the  bank,  in  terms  of 
the  number  of  messages,  the  size  of  a  digital  coin,  and  the 
size  of  a  ticket  number,  are  similarly  small. 


Current  Costs  in  Tor.  To  get  a  more  concrete  idea  of  what 
the  costs  at  the  bank  might  be  in  practice,  we  estimate  what 
it  would  cost  for  a  bank  to  serve  the  current  Tor  network. 
In  Tor,  b  =  1700  and  £  =  3.  The  most  costly  operation  by 
one  to  two  orders  of  magnitude  is  signature  generation.  In  the 
above  setting,  the  rate  of  signature  generation  is  127.5+127.5/ 
per  second,  where  again  /  G  [0, 1].  OpenSSL  benchmarks  in 
Linux  on  an  Intel  Core2  Duo  2.67  GHz  machine  show  that  it  is 
capable  of  creating  1705  1024-bit  RSA  signatures  per  second, 
and  thus  a  modest  machine  is  easily  capable  of  generating  the 
required  signatures. 

We  also  estimate  the  communication  costs  at  the  bank  in 
this  setting  by  using  a  signature  size  of  1024  bits  and  a  ticket- 
number  size  of  A  =  320  bits.  Then  the  bank  sends  at  a  total 
rate  of  15.94  +  25.90/  KiB/s  and  receives  at  a  total  rate 
of  15.94  +  41.84/  KiB/s,  easily  manageable  with  a  single 
consumer-grade  network  connection. 

Comparison  to  BRAIDS.  To  further  understand  LIRA’S 
efficiency,  we  compare  it  to  the  efficiency  of  BRAIDS  [21],  the 
state-of-the-art  Tor  relay  incentive  design.  The  cost  for  each 
client  in  LIRA  and  BRAIDS  are  similar,  however,  only  the 
clients  that  are  purchasing  guaranteed  winners  must  pay  this 
cost  in  LIRA  as  opposed  to  all  clients  that  receive  free  tickets 
in  BRAIDS.  Further,  a  relay  verifying  winners  in  LIRA  is  at 
least  an  order  of  magnitude  more  efficient  than  a  relay  veri¬ 
fying  tickets  in  BRAIDS;  our  OpenSSL  benchmarks  indicate 
lira’s  winner  verification  (6  SHA-1  hashes)  takes  roughly 
18  microseconds,  whereas  a  BRAIDS  ticket  verification  takes 
roughly  1500  microseconds  [21]  on  the  same  hardware. 

The  most  important  cryptographic  cost  is  at  the  bank. 
lira’s  bank  only  needs  to  cryptographically  pay  the  relays 
for  some  fraction  of  the  total  traffic  due  to  its  lottery  design. 
On  the  other  hand,  the  bank  in  BRAIDS  pays  for  all  traffic 
by  distributing  tickets  to  all  clients.  In  addition,  the  number 
of  ticket  purchases  is  proportional  to  the  amount  of  e-cash 
actually  used  by  the  relays  to  obtain  prioritized  service.  If,  as 
we  expect,  many  relays  altruistically  provide  more  service  than 
needed  to  support  their  own  use,  the  system  gains  significant 
efficiency  over  distributing  tickets  to  clients. 

If  we  change  the  parameters  of  the  BRAIDS  scheme  to  more 
conservatively  compare  LIRA^,  we  observe  that  BRAIDS  re¬ 
quires  at  least  637.5  signatures  per  second.  Even  if  /  =  1  and 
relays  spend  all  their  credit,  LIRA  is  more  efficient.  Moreover, 
BRAIDS  requires  a  less  computationally  efficient  partially- 
blind  signature  scheme.  The  signature-generation  protocol 
in  BRAIDS  also  has  higher  communication  costs  in  both 
directions  than  RSA  blind  signatures,  and  thus  is  easily  greater 
than  lira’s  costs  in  both  directions. 


^We  suppose  that  BRAIDS  creates  tickets  for  only  half  of  the  network 
traffic,  as  it  is  designed  to  cover  Web  traffic  (58%  of  Tor  traffic  [29]). 
Also,  we  allow  each  ticket  to  buy  lOMiB  of  priority,  as  in  LIRA,  and  we 
give  relays  a  bytes  sent/eamed  ratio  of  1/4,  also  as  in  LIRA.  We  then  have 
(1700*3)/(2*4*10)=63.75  tickets  created  per  second,  which  yields  63.75*20/2 
=  637.5  total  signatures  per  second  when  ticket  exchanges  are  included. 


B.  Anonymity 

We  are  interested  in  the  extent  to  which  the  use  of  LIRA 
affects  the  anonymity  of  onion  routing.  Onion  routing  security 
is  well-explored  in  the  literature  [24],  [34],  [35],  [36],  [37], 
and  its  vulnerabilities  generally  exist  after  adding  our  incentive 
system.  Therefore,  our  goal  is  to  prevent  whatever  anonymity 
is  provided  by  onion  routing  from  being  significantly  de¬ 
graded.  In  this  section  we  denote  by  negl(A)  a  function  that 
is  negligible  in  A 

Single  Connection.  Consider  first  a  network  adversary  ob¬ 
serving  a  single  connection  below  the  priority  cutoff  length 
of  p.  If  the  adversary  is  observing  at  a  guard  node,  the  user 
may  be  identified  as  running  a  relay  if  he  is  connecting  to  the 
guard  from  it.  However,  the  multiple  connections  case  shows 
that  this  would  be  quickly  learned  by  the  guard  anyway.  Thus 
it  is  a  good  idea  for  the  user  to  use  his  own  relays  as  guards. 

Assuming  the  adversary  is  not  observing  at  a  guard  node, 
from  the  adversary’s  perspective,  LIRA  simply  adds  TICKET 
cells  and  status  signaling  messages  between  pairs  of  relays. 
Users  only  directly  affect  the  TICKET  cells.  Guessers  and 
buyers  generate  these  cells  according  to  different  distributions, 
potentially  leading  to  some  deanonymization.  The  difference 
lies  in  the  probability  that  the  TICKET  cells  contain  a  winner 
or  not.  Therefore,  we  need  only  consider  an  adversary’s 
observations  about  whether  or  not  the  user  inserts  winning 
tickets  into  each  of  the  relays  on  a  circuit. 

Suppose  that  a  user  does  provide  winners  for  an  entire 
circuit.  This  happens  with  probability  1  for  buyers  and  for 
guessers.  The  adversary  can  easily  learn  that  submitted  tickets 
were  winners  if  he  controls  one  of  the  circuit’s  relays.  He  may 
also  learn  this  by  observing  the  speed  of  traffic  to  and  from 
a  destination  under  his  observation.  Over  time,  the  adversary 
can  learn  the  distribution  of  traffic  speeds  for  prioritized  and 
unprioritized  traffic  and  use  the  separation  between  these  (as 
demonstrated  in  Section  V)  to  infer  the  priority  status  of  a 
given  observed  connection.  Assume  that  buyers  consist  of 
the  m  relays  and  guessers  consist  of  the  other  users  of  the 
network  at  a  given  time,  and  that  each  user  is  a  priori  equally- 
likely  to  create  a  circuit.  Then  the  probability  that  the  source 
of  a  connection  is  a  given  relay,  based  only  on  its  circuit 
prioritization  status,  is  l/{m  +  {n  —  m)p^),  and  the  probability 
that  it  is  a  given  non-relay  is  p^/ {m  +  {n  —  m)p^). 

Now  suppose  that  a  user’s  tickets  are  not  winners  for  the 
entire  circuit.  This  happens  with  probability  0  for  buyers  and 
1  —  p^  for  guessers.  As  before,  the  adversary  can  determine 
this  in  several  ways.  Buyers  never  fail  to  provide  a  winner, 
and  so  the  adversary  can  infer  that  the  source  is  a  guesser. 
Given  n  —  m  guessers,  the  probability  that  the  source  is  a 
given  one  is  l/{n  —  m).  (Of  course  buyers  could  intentionally 
fail  to  submit  winning  tickets  at  some  relays  periodically  to 
complicate  this  analysis.  We  do  not  evaluate  such  possibility 
in  this  paper.) 

We  are  most  interested  in  the  case  that  there  are  relatively 

^A  function  /  that  is  negligible  in  A  decreases  faster  with  A  than  any 
inverse  polynomial.  That  is,  /(A)  =  o(l/A*^)  for  any  k. 


few  buyers,  as  that  would  be  true  currently  if  LIRA  were 
deployed  in  Tor,  and  we  would  expect  it  to  remain  so  as  long 
as  the  cost  of  running  a  relay  is  high  relative  to  the  benefit 
of  anonymity  for  most  users.  In  this  case,  the  probability 
that  a  given  buyer  is  the  source  of  a  single  short  prioritized 
connection,  based  only  on  its  circuit  prioritization  status,  is 
roughly  l/(m  +  np^).  With  p  —  this  becomes 

l/{m  +  ^/n).  Thus,  we  can  see  that  uncertainy  over  the  source 
increases  with  the  total  number  of  users  n,  a  desirable  property 
of  onion  routing  that  we  want  to  preserve.  With  few  buyers, 
the  probability  that  a  given  guesser  is  the  source  of  a  single 
short  unprioritized  connection,  based  only  on  the  circuit’s 
prioritization  status,  is  roughly  1  /n,  which  is  the  best  possible. 

Of  course,  an  adversary  need  not  only  take  into  account  the 
prioritization  status  of  a  relay  for  purposes  of  deanonymiza¬ 
tion.  Indeed,  as  discussed,  all  attacks  on  onion  routing  it¬ 
self  maybe  be  used  in  addition  to  the  information  provided 
by  LIRA.  However,  the  action  of  the  incentive  system  is 
independent  of  the  underlying  onion  routing  protocol,  and 
therefore  the  effect  on  deanonymization  is  simply  to  weight  the 
distribution  an  adversary  would  otherwise  infer.  For  example, 
suppose  that,  excluding  the  observations  from  the  incentive 
system,  the  adversary  can  infer  that  the  source  is  a  given  user 
with  probability  pi .  If  that  user  has  probability  p2  of  achieving 
the  priority  observed,  then,  including  those  observations,  the 
probability  of  the  user  becomes  (proportional  to)  pip2-  One 
consequence  of  this  as  that  LIRA  increases  the  posterior 
probability  of  a  buyer  by  at  most  1/p^. 

Multiple  Connections.  Circuits  on  which  more  than  /?  bytes 
are  sent  include  multiple  TICKET  cells  from  users.  The  above 
analysis  applies  to  any  one  priority  status,  but  taken  together 
they  degrade  the  anonymity  of  the  user  to  the  point  that  they 
are  essentially  identified  as  either  a  buyer  or  a  guesser.  Suppose 
a  user’s  circuit  transfers  more  than  {k  —  l)/3  bytes.  This  will 
happen  when  a  single  connection  exceeds  that  amount.  It  can 
also  happen  if  the  total  volume  of  multiple  connections  sent 
over  the  same  circuit  exceed  that  amount.^  In  this  situation  the 
user  updates  his  priority  status  k  times.  The  probability  that 
a  guesser  maintains  priority  through  all  the  updates  is  p^^. 
Therefore,  such  a  circuit  created  by  a  buyer  quickly  identifies 
him  as  a  buyer,  and  the  probability  that  it  is  a  given  buyer 
conditional  only  on  the  priorities  observed  is  l/{m  +  in  — 
m)p^^).  Guessers  are  always  identified  as  guessers  when  the 
tickets  they  submit  fail  to  be  winners,  and  this  happens  with 
an  increasing  likelihood  of  1  —  p^^. 

Users  making  many  circuits  over  time  face  the  possibility  of 
a  similar  decrease  in  anonymity.  If  an  adversary  can  observe 
the  priority  status  of  fc  of  a  user’s  connection  and  link  them 
together  as  belonging  to  the  same  (unknown)  user,  the  resulting 
anonymity  is  just  as  if  the  user  updated  the  priority  status  of 
a  given  circuit  k  times.  Some  ways  the  adversary  may  be 
able  to  link  connections  include  controlling  a  destination  at 

^The  amount  of  traffic  sent  over  a  circuit  depends  on  the  relative  rates  at 
which  circuits  and  connection  are  created  and  destroyed.  Tor  only  puts  new 
connections  on  circuits  that  have  been  used  for  less  than  ten  minutes,  with  a 
preference  among  used  circuits  for  the  youngest. 


which  users  are  active  over  long-lived  sessions,  controlling 
some  exit  nodes  and  linking  together  connection  by  related 
activities,  and  controlling  some  middle  nodes  and  observing 
connections  coming  from  the  same  guard  nodes.  The  adversary 
is  also  be  able  to  link  connections  at  a  guard  node  because 
they  come  from  the  source  directly.  A  user  running  a  relay 
may  hope  to  hide  that  fact  from  a  given  guard  by  connecting 
to  the  anonymity  network  from  a  different  location  and  buying 
tokens  from  a  guard  anonymously  through  a  different  guard. 
However,  if  he  consistently  buys  priority,  his  guards  will 
quickly  determine  that. 

We  note  that  hiding  over  the  long  term  the  fact  that  better 
service  is  being  purchased  seems  to  be  a  fundamental  issue  that 
any  scheme  will  suffer  from  to  some  degree.  In  BRAIDS  [21], 
for  example,  normal  users  receive  fewer  coins  than  relays,  and 
so  they  can  only  be  confused  with  relays  if  they  save  up  many 
coins  before  buying,  and  thus  few  of  them  can  buy  at  any  one 
time.  On  the  other  hand,  allowing  users  to  purchase  service 
without  running  a  relay,  which  we  ignored  in  our  analysis  due 
to  uncertainty,  has  the  potential  to  attract  many  more  users  than 
those  that  run  relays.  The  Torservers.net  project  [14]  already 
demonstrates  that  many  prefer  donating  money  to  running 
relays.  (Note  that  this  also  presents  a  mechanism  whereby 
purchasing  priority  can  indirectly  add  commensurate  capacity 
to  the  network  if  all  proceeds  of  such  sales  are  directed  into 
the  purchase  of  more  capacity,  such  as  Torservers.net  does.)  In 
addition,  the  widespread  use  of  VPNs  for  Internet  security  and 
blocking  resistance  indicate  a  willingness  to  pay  for  privacy. 
Bank  Privacy.  We  assume  that  the  bank  is  semi-honest  and 
only  observes  messages  sent  to  it.  The  bank  only  observes  the 
amount  of  e-cash  earned  by  relays,  when  cash  is  transferred 
among  users,  and  the  purchase  of  winners.  Clearly,  then, 
the  bank  doesn’t  learn  anything  about  the  destinations  of 
connection  through  the  anonymity  network,  and  therefore 
users  have  relationship  anonymity  with  respect  to  the  bank. 
However,  LIRA  protects  user  privacy  even  further. 

First,  all  bank  purchases  are  made  using  anonymous  connec¬ 
tions  and  anonymous  coins.  Therefore  the  bank  doesn’t  learn 
who  is  spending  e-cash  and  buying  service  in  the  network. 

Second,  clients  batch  and  randomly  time  their  purchase 
of  ticket  winners  to  hide  when  prioritized  circuits  are  made 
from  the  bank.  Clients  should  purchase  'yi  winning  tickets 
at  a  time.  If  a  relay  prioritizes  all  his  circuits  and  makes 
them  at  Tor’s  rate  r  «  1  per  minute,  he  purchases  winners 
every  7  =  26  minutes.  Moreover,  the  time  of  the  purchase 
triggered  by  a  prioritization  that  reduces  a  client’s  reserve 
of  winners  below  the  7/2  threshold  is  hidden  from  a  bank 
within  a  period  of  w  =  13  minutes.  To  get  an  idea  of  how 
many  other  prioritizations  occur  during  these  time  periods, 
consider  n  =  10000  users  making  circuits  at  rate  r,  each 
gaining  priority  with  probability  p^  =  Ijy/n.  Then  during 
a  26  minute  period  between  purchases  there  are  an  expected 
'ynp^r  =  2600  prioritized  circuits  from  other  users  and  during 
a  13  minute  period  there  are  an  expected  1300  such  circuits. 

Third,  the  Winner  Purchase  Protocol  hides  from  the  bank  the 
relay  identity  and  the  ticket  number  of  a  purchased  winner.  The 


1.  B  sends  challenge  relays  tq  ^  ri  to  C. 

2.  C  chooses  a  random  bit  z  G  {0, 1}. 

3.  C  obtains  a  coin  from  B. 

4.  C  executes  the  Winner  Purchase 
Protocol  with  B  for  relay 

5.  B  outputs  a  guess  z'  for  the  value  of  z. 

6.  The  experiment  value  is  1  if  z'  =  z,  0  if  not. 

Fig.  7;  WPP-REL-IND  experiment  between  B  and  C 


indistinguishability  experiment  WPP-REL-IND  between  the 
bank  B  and  a  challenger  C  shown  in  Figure  7  tests  how  well 
the  bank  can  determine  the  relay  of  a  purchase.  Theorem  1 
shows  that  the  observations  a  bank  makes  during  a  purchase 
for  given  relay  are  indistinguishable  from  the  observations 
made  during  a  purchase  for  a  different  relay. 

Theorem  1:  In  the  Random  Oracle  Model, 
Pr[WPP-REL-IND  =  1]  <  1/2  -f  negl(A). 

Proof:  Model  H  as  a  Random  Oracle.  Let  Z  represent 
the  random  bit  chosen  in  Step  2  of  the  WPP-REL-IND 
experiment.  We  compare  this  experiment  when  Z  =  0  and 
Z  =  1  and  show  that,  except  with  negligible  probability,  a 
given  view  of  the  adversary  is  equally  likely  in  both  cases. 
Let  B  make  queries  Qii  Q2,  ■  •  ■ ,  Qt  to  i7  in  that  order  during 
the  experiment. 

C  begins  the  experiments  for  both  Z  =  0  and  Z  =  1  by 
paying  B  a  coin.  Coin  generation  and  payment  is  independent 
of  relay  selection,  and  thus  the  observations  B  makes  as  part 
of  those  processes  does  not  affect  the  probability  of  later 
observations  and  can  be  ignored. 

Next,  C  chooses  O  <  To,  Li  <  2'’'/^  such  that  Tq  0  Ti  < 
p2^/2.  We  can  view  C  as  choosing  Yi  independently  and 
uniformly  at  random  such  that  O  <  Yi  <  2^/^.  This  implies 
that  C  chooses  Tq  in  Step  2  independently  and  uniformly  at 
random  from  the  p2^/^  values  that  satisfy  0  <  Tq  0  Ti  < 
p2^/^.  We  let 

Y2=frAYl) 

=  Yo(BHiYiH{H{Yi)xf^ 

denote  the  value  to  be  computes  in  Step  3  of  the  Permutation 
Protocol.  Then  we  can  define  Collision  to  be  the  event  that 
Qi  =  Yi  or  Qi  =  Y2  for  any  I  <  i  <t. 

C  next  sends  a^Xrz  to  B  to  obtain  the  blinded  signature 
where  a  is  chosen  independently  and  uniformly  at 
random.  As  in  the  preceding,  this  observation  can  thus  be 
ignored. 

Next,  C  sends  Xi  =  bH{Yi)xf^  to  B.  Consider  the 
queries  Qi,  ■  ■  ■  ,Qti  that  occur  before  C  queries  H{Yi).  Yi 
is  independent  of  all  observations  of  B  at  this  point,  and 
therefore  the  probability  that  Qi  =  Yi  for  some  1  <  z  <  is 
2“^/^  G  negl(A).  Similarly,  Tq  is  independent  of  all  of  B’s 
observations,  and  thus  the  probability  that  Qi  =  Y2  for  some 
1  <  z  <  ft  is  p2“^/^  G  negl(A).  Assume  from  this  point  on 
that  this  doesn’t  happen. 


The  result  of  the  query  Yi  to  H  is  thus  independently  and 
uniformly  random.  Thus  the  probability  of  Xi  is  the  same 
whether  Z  =  0  or  Z  =  1.  The  former  case,  of  course, 
implies  that  H{Yi)  =  Xi/{hxf^),  while  the  latter  implies  that 
H{YQ=XQ{bxi^). 

The  next  message  from  C  to  i?  is  X2  =  bH{Y2)xf^. 
Let  Qi,...,Qt2  be  the  queries  that  B  makes  to  H  up  to 
the  point  that  C  queries  Y2.  We  have  already  assumed  that 
Qi  ^  {Yi,Y2}  for  1  <  z  <  <1. 

■ 

We  can  define  an  experiment  similar  to  WPP-REL-IND 
to  test  how  well  the  bank  can  guess  the  ticket  number  of 
a  purchase.  It  can  be  shown  that  the  bank  succeeds  in  that 
experiment  with  at  most  a  negligible  amount  over  a  random 
guess  as  well. 

C.  Incentives 

LIRA  is  designed  to  create  an  incentive  for  users  to  run 
relays  or  otherwise  contribute  to  the  system.  We  explore  in 
Section  V  the  extent  to  which  it  successfully  provides  better 
service  to  users  that  receive  priority.  Here  we  consider  if  users 
must,  as  we  intend,  earn  e-cash  in  order  to  increase  the  amount 
of  priority  they  can  obtain.  Again  we  denote  by  negl(A)  a 
function  that  is  negligible  in  A. 

We  first  note  that  the  possibility  of  cheating  the  system 
is  an  important  consideration  but  one  less  important  than 
performance  and  preserving  anonymity.  Regardless  of  whether 
or  not  a  user  can  deviate  from  the  protocol  to  obtain  more 
priority,  the  anonymity  and  performance  properties  of  the 
system  still  hold.  Thus  system  operators  could  experiment 
with  the  use  of  LIRA  without  compromising  the  properties  the 
network  already  provides.  Furthermore,  the  amount  of  cheating 
that  will  occur  in  practice  in  a  network  protocol  is  unclear. 
BitTorrent,  for  example,  is  susceptible  to  cheating  [38],  [39], 
but  it  tends  to  perform  well  in  practice.  Somewhat  low  barriers 
to  cheating  may  well  be  sufficient  to  induce  most  participants 
to  comply. 

LIRA  is  designed  to  force  users  to  pay  in  order  to  obtain 
a  winner  with  probability  greater  than  p.  It  achieves  this  by 
using  an  e-cash  scheme  and  a  novel  cryptographic  lottery. 

In  the  e-cash  scheme,  users  must  present  valid  digital  coins 
to  participate  in  the  Winner  Purchase  Protocol  (Fig.  4).  The 
e-cash  scheme  prevents  coin  forgery  or  double  spending. 

The  winners  themselves  are  obtained  by  participating  in  the 
Permutation  Protocol  (Fig.  3).  This  protocol  allows  users  to 
observe  much  more  about  than  just  the  output.  However, 
the  intermediate  PRF  outputs  that  the  users  observe  are  only 
allowed  by  a  relay  to  appear  in  one  winner.  If  another  ticket 
is  submitted  with  a  previously  seen  PRF  value,  the  relay  will 
treat  it  as  a  loser.  Thus  these  intermediate  values  are  of  no  use 
in  producing  more  winners  than  were  paid  for,  and  on  inputs 
with  unseen  intermediate  PRF  values,  the  XOR  of  the  halves 
of  the  lottery  permutation  does  indeed  appear  random. 

We  formalize  this  property  in  the  security  experiment  PP 
between  an  adversary  A  and  a  challenger  C  shown  in  Figure  8. 
We  will  show  that  A  succeeds  in  this  experiment  with  at  most  a 


1.  A  outputs  relays  r  =  {ri, . . . ,  r^} 
and  a  challenge  relay  ^  r. 

2.  C  outputs  random  values  {x^ ,  ■  •  ■ , 
in  Zd  and  signatures  {xf^, ..  .,xf^}. 

3.  C  executes  the  Permutation  Protocol  with  A 
as  many  times  t  as  requested. 

4.  A  outputs  X  =  {xx, . . .  ,xt+i}. 

5.  If  Vij/o  ®y\<  where  yl\\y\=  gr^ {x,) 

and  no  intermediate  PRF  input  would  be  reused 
during  protocol  evaluations  of  the  gr^{xi), 

the  experiment  value  is  1;  else  it  is  0. 

Fig.  8;  PP  experiment  between  A  and  C 


1.  C  generates  RSA  parameters  {M,e,d) 
and  outputs  (M,  e). 

2.  A  outputs  relays  r  =  {ri, . . . ,  Xk} 
and  a  challenge  relay  Tc 

4.  C  outputs  random  values  {xr^ ,  ■  ■  ■ ,  Xr^ ,  Xr^ } 
in  Zd  and  signatures  {x'}^ ,  x'J:^}. 

5.  C  executes  the  PRF  Protocol  with  A  some  t 
number  of  times. 

6.  A  outputs  X  =  {xi, . . .  ,xt},  {yi, . . . ,  yt},  Xc  ^  x. 

7.  C  randomly  chooses  z  G  {0, 1}. 

8.  C  outputs  {xc)  if  z  =  0  and  else  a  random  y. 

9.  A  outputs  a  guess  z' .  The  experiment  value  is  1 
if  z'  =  z  and  =  fr^{xi).  Otherwise  it  is  0. 

Fig.  9;  PRF  experiment  between  A  and  C 

negligible  probability  greater  than  p.  But  hrst,  we  show  that  the 
PRF  Protocol  actually  provides  the  PRF  properties.  The  PRF 
experiment  shown  in  Figure  9  tests  whether,  after  executing  the 
PRF  Protocol  some  arbitrary  number  of  times  t,  an  adversary 
A  can  distinguish  (x)  from  a  random  value  for  more  than 
t  inputs  X,  where  Xc  is  some  challenge  relay.  Lemma  1  shows 
that  the  adversary  succeeds  in  this  experiment  with  probability 
at  most  a  negligible  amount  over  random  chance. 

Lemma  1:  In  the  Random  Oracle  Model  and  under  the  RSA 
assumption,  Pr[PRF  =  1]  <  1/2  +  negl(A). 

Proof:  We  can  reduce  winning  this  game  to  solving  the 
RSA  problem.  We  construct  a  simulator  S  for  the  PRF  chal¬ 
lenger  C  and  random  oracle  H.  S  implements  H  internally.  S 
implements  parameter  selection  by  relaying  RSA  parameters 
from  the  RSA  challenger  to  PRF  adversary  A.  S  randomly 
selects  the  relay  signatures  xf.,  computes  the  relay  values 
Xn  from  them,  and  randomly  selects  Xr^-  S  executes  the 
challenger  side  of  the  PRF  Protocol  by  storing  the  response 
values  Wi  =  H{xi)  output  by  A  and  using  random  values  vt 
for  each  H{H{xi)xfJ. 

Step  1  of  the  PRF  Protocol  is  random,  and  so  the  distribution 
of  these  values  given  A’s  view  is  accurately  produced  by  S. 
The  value  for  H{H{xi)xf  )  is  indeed  random  in  A’s  view 
unless  the  response  from  A  in  Step  2  of  the  PRF  Protocol 
is  such  that  xf^Wi  is  equal  to  some  value  queried  of  H  by 


A.  S  can  check  for  this  possibility  by  dividing  all  queries 
for  H  by  each  new  wi  received  from  A,  raising  it  to  the 
power  e,  and  comparing  to  Xr^-  If  any  verihcation  succeeds, 
S  submits  that  value  to  the  RSA  challenger.  Under  the  RSA 
assumption,  the  probability  that  this  happens  is  negligible. 
Assuming  this  doesn’t  happen,  C  randomly  chooses  a  bit  z  and 
outputs  a  random  y.  If  the  outputs  Xi  and  yi  of  A  are  such  that 
H{xi)  =  Wi  and  yi  =  H{viXi),  then  S  has  not  “programmed” 
H  with  a  value  for  H{xc)xf  (i.e.  choosing  a  value  without 
knowing  the  input).  S  again  checks  if  H{xc)xf  has  been 
queried  by  dividing  all  queries  by  H{xc)  and  raising  to  the  e, 
sending  to  the  RSA  challenger  if  so.  Thus  this  happens  with 
negligible  probability.  Assuming  it  hasn’t,  frA^c)  is  random 
from  A’s  perspective,  and  the  random  y  from  C  has  the  correct 
distribution,  z  is  random  and  independent  of  y,  and  thus  z'  =  z 
with  probability  1/2. 

Therefore,  overall  C  presents  the  correct  view  to  A  except 
with  negligible  probability,  and  thus  we  have  Pr[PRF  =  1]  < 
l/2  +  negl(A).  ■ 

Using  Lemma  1,  we  can  now  show  that  the  adversary  does 
not  have  an  advantage  in  hnding  more  than  t  winners  under 
the  permutation  g^. 

Theorem  2:  In  the  Random  Oracle  Model,  Pr[PP  =  1]  < 
p  +  negl(A). 

Proof:  After  executing  the  Permutation  Protocol  t  times, 
A  only  obtains  the  value  of  on  2t  inputs.  Therefore,  among 
the  2(f  +  1)  values  to  which  is  applied  according  to 
Equation  2,  there  must  be  at  least  one  repeated  value  or  one 
on  which  A  has  not  evaluated  fr^ .  If  there  is  a  repeated  value, 
then  the  experiment  value  is  0.  Otherwise,  there  is  an  unknown 
evaluation  of  fr^  that  appears  random  to  A  by  Lemma  1 .  If  this 
input  to  fr^  appears  as  half  of  one  of  the  Xi,  the  probability 
that  its  value  under  results  in  a  known  input  to  in  the 
next  Feistel  permutation  is  thus  negligible,  and  so  one  half 
of  grAxi)  appears  random  to  A.  If  the  unknown  input 
appears  after  the  hrst  Feistel  permutation  of  some  Xi,  one  half 
of  grAxi)  again  appears  random  to  A.  In  either  case,  the  XOR 
of  the  halves  of  some  g^Axi)  appears  random  to  A.  Thus  that 
Xi  is  a  winner  with  probability  negligibly  close  to  p.  ■ 

While  this  theorem  shows  that  users  can  only  themselves 
produce  unused  winners  with  probability  p,  a  user  may  try  to 
game  the  network  by  creating  circuits  and  determining  their 
priority.  If  he  attempts  to  do  so  without  colluding  with  any 
relays,  he  must  determine  the  priority  of  the  circuit  from  its 
performance  alone.  Suppose  that  doing  so  requires  that  he 
send  or  receive  at  least  c  cells  on  a  circuit.  Then,  to  obtain 
a  circuit  with  priority,  the  user  must  transfer  an  expected  c/p 
total  cells.  If  the  cost  of  tranferring  these  cells  is  comparable  to 
the  amount  of  traffic  a  relay  needs  to  transfer  in  order  to  earn 
enough  coins  to  build  a  circuit,  a  rational  user  might  choose 
to  take  that  more-reliable  option. 

A  user  might  also  run  or  collude  with  a  relay  in  order  to 
obtain  priority  without  paying.  A  relay  on  a  circuit  is  able 
to  determine  from  the  messages  between  adjacent  relays  on 
a  circuit  its  priority  status.  Therefore,  a  user  could  collude 
with  a  guard  node  to  create  and  destroy  circuits  until  one  with 


priority  is  obtained.  Similarly,  the  user  could  collude  with  a 
middle  or  exit  node,  although  given  that  the  user  in  this  case 
is  presumably  known  to  the  colluding  relay,  it  would  seem 
only  to  improve  performance  without  decreasing  anonymity 
to  directly  connect  to  that  relay.  A  simple  remedy  for  this 
attack  that  renders  it  equivalent  to  testing  and  creating  circuits 
is  to  defer  the  activation  of  priority  on  a  circuit  until  some 
number  c  of  cells  have  passed  in  either  direction.  The  initial 
traffic  on  a  circuit  is  fast  even  without  priority  due  to  EWMA 
scheduling,  and  so  the  performance  impact  should  be  minimal, 
although  we  have  not  implemented  it  in  our  experiments.  An 
additional  possible  attack  is  for  a  colluding  relay  in  the  middle 
of  the  circuit  to  lie  about  the  priority  status  of  either  side  in 
order  to  get  partial  priority  of  a  circuit.  However,  we  again 
observe  that  it  would  seem  to  make  little  sense  for  a  user  to 
use  a  colluding  relay  as  a  middle  node  rather  than  connect 
directly.  Also,  for  all  attacks  that  involve  a  relay,  the  costs 
associated  with  running  a  relay  are  already  being  paid,  and 
it  would  have  to  be  the  case  that  the  cost  of  simply  adding 
capacity  is  more  than  the  cost  of  running  a  cheating  scheme. 

Finally,  we  observe  that  similar  opportunities  for  cheating 
exist  in  other  recent  incentivization  schemes  for  anonymous 
communication.  The  Tortoise  scheme  of  Moore  et  al.  [9] 
allows  users  to  create  many  circuits  to  avoid  throttling,  similar 
to  the  multiple-circuits  attacks  in  LIRA.  Also,  the  BRAIDS 
design  of  Jansen  et  al.  [21]  is  susceptible  to  malicious  guards 
as  well,  in  that  guards  can  easily  steal  the  winning  tickets 
intended  for  their  users.  Thus  while  LIRA  does  not  eliminate 
cheating,  it  does  offer  a  substantially  new  balance  among 
competing  priorities. 

V.  Experiments 

We  simulate  LIRA  in  an  effort  to  understand  the  perfor¬ 
mance  benefits  possible  when  running  our  incentive  scheme. 
Our  experiments  are  done  using  Shadow  [40],  a  scalable, 
high-fidelity  network  simulator  that  is  capable  of  running  real 
Tor  binaries  as  plug-ins  (using  the  available  Shadow  plug-in 
called  Scallion  [41]).  Shadow  allows  us  to  create  a  private 
Tor  network  on  a  single  machine  and  avoid  privacy  risks 
associated  with  live  network  experiments.  Shadow  experiments 
are  completely  controllable  and  repeatable,  and  are  faithful  to 
Tor’s  protocols  since  Shadow  runs  the  real  Tor  software.  In 
this  section,  we  describe  our  configured  experimental  network 
environment,  quantify  its  consistency  with  public  Tor  network 
performance,  and  explore  how  LIRA  affects  performance  and 
improves  incentives  for  a  variety  of  users.  Note  that  all  of  the 
experiments  described  in  this  section  are  repeated  ten  times  to 
diminish  random  experimental  variances,  and  each  uses  Tor 
software  version  0.2.3. 13-alpha. 

A.  Network  Model 

Shadow  requires  a  complete-graph  network  topology  that 
includes  properties  such  as  upstream  and  downstream  band- 
widths,  latency,  jitter,  and  packet  loss.  As  network  modeling 
is  itself  a  challenging  research  problem,  we  rely  on  previous 
Tor  network  modeling  contributions  by  Jansen  et  al.  [42]. 


Their  work  considers  every  element  of  the  Internet  and  the 
Tor  network  itself  that  must  be  modeled  to  run  accurate  Tor 
experiments  in  Shadow.  Their  model  is  built  using  real  Internet 
measurements  from  GeoIP  [43],  iPlane  [44],  [45],  and  Net 
Index  [46],  and  is  validated  with  multiple  experimentation 
platforms  and  data  from  the  live  Tor  network  itself  [23]. 

We  now  give  an  overview  of  the  Tor  network  model  used 
in  our  experiments  and  discuss  how  it  was  modified  from  the 
original,  the  full  details  of  which  are  presented  in  [42].  Our 
private  Tor  network  consists  of  50  generic  HTTP  servers,  50 
Tor  relays,  500  Tor  clients.  Of  the  50  Tor  relays,  there  is  1 
directory  authority,  20  exit  relays,  and  29  non-exit  relays. 

Although  the  original  model  configured  475  web  and  25 
bulk  clients,  a  wider  range  of  client  applications  would  provide 
a  more  realistic  traffic  distribution.  Therefore,  we  slightly 
modify  the  clients  to  better  approximate  Tor’s  protocol  distri¬ 
bution  as  described  in  [29]  and  [47].  We  configure  10  instant 
messaging  clients  (im),  465  web  HTTP  clients  (web),  20  bulk 
HTTP  clients  (bulk),  and  5  peer-to-peer  clients  (p2p).  The 
im  clients  download  1  KiB  files,  pausing  for  one  to  five 
seconds  after  finishing  one  download  and  before  starting  the 
next.  The  web  clients  download  320  KiB  files  and  pause  for 
1  to  20  seconds.  The  bulk  clients  continuously  download  5 
MiB  files  without  pausing.  All  of  the  im,  web,  and  bulk 
clients  choose  a  random  HTTP  server  for  each  download.  The 
p2p  clients  form  a  “swarm”  around  a  single  700  MiB  file 
that  is  managed  by  a  p2p  authority.  Each  pair  of  p2p  nodes 
connect  and  continuously  exchange  16  KiB  blocks  of  the  file 
without  pausing.  Payload  download  times  are  measured  as  an 
indication  of  network  performance. 

Model  and  Simulation  Accuracy.  As  we  modified  the  model 
as  originally  described  and  validated  in  [42],  we  re-evaluate 
the  consistency  of  Shadow’s  results  with  live  network  data. 
To  determine  how  well  our  modeled  network  approximates 
client  performance  in  the  public  Tor  network,  we  compare 
download  times  in  a  vanilla  Tor  experiment  with  measurements 
of  Tor  collected  by  the  TorPerf  measurement  system  [48]. 
TorPerf  downloads  50  KiB,  1  MiB,  and  5  MiB  files  through 
the  Tor  network  to  monitor  performance,  and  records  various 
download  times.  Because  our  clients  download  differently 
sized  files  than  TorPerf,  we  compare  the  time  to  receive  the 
last  byte  of  each  of  our  experimental  downloads  with  the 
time  to  receive  the  closest  byte  that  is  reported  by  TorPerf. 
As  shown  in  Figure  10,  Shadow  does  a  reasonable  job  of 
characterizing  the  expected  performance  of  the  public  Tor 
network.  Performance  for  im  and  p2p  clients  are  consistent 
with  TorPerf  measurements  (Figure  10a),  as  are  web  and 
bulk  downloads  below  approximately  the  fiftieth  percentile 
(Figure  10b). 

The  difference  in  performance  in  the  upper  half  of  the 
distributions  is  possibly  due  to  Tor’s  scheduling  policy  [11], 
in  which  circuit  priority  decreases  as  its  throughput  increases. 
TorPerf  will  have  higher  expected  priority  than  clients  in  our 
experiments  since  TorPerf  downloads  once  per  circuit  whereas 
our  clients  download  multiple  times  per  circuit.  Note  that  we 
were  unable  to  confirm  this  suspicion  beyond  reasonable  doubt 


(a)  im  and  p2p  clients  (b)  web  and  bulk  clients 

Fig.  10:  Shadow  and  public  Tor  performance  are  reasonably  consistent  for  various  transfer  sizes. 


due  to  a  lack  of  experimental  single  file  circuit  downloads. 

B.  LIRA  Prototype 

We  implement  a  research  prototype  of  LIRA  as  described 
in  Section  III  by  directly  modifying  the  Tor  source  code. 
To  understand  how  to  attribute  changes  in  performance,  we 
run  separate  experiments  using  the  default  EWMA  circuit 
scheduling  algorithm  (vanilla  Tor),  our  new  Proportional 
Throughput  Differentiation  scheduler  (diffserv)  based  on  work 
by  Dovrolis  et  al.  [33]  (see  Section  III-E),  and  various  LIRA 
configurations  (lira). 

Class  Differentation.  We  configure  our  new  prototype  sched¬ 
uler  with  “paid”  and  “unpaid”  classes  ci  and  C2,  and  dif¬ 
ferentiation  parameters  pi  —  1.0  and  p2  =  10.0.  Priorities 
are  weighted  by  taking  fraction  /  =  0.875  of  the  head-of- 
queue  circuit  EWMA,  and  0.125  of  the  long-term  class  average 
EWMA.  The  EWMA  throughput  algorithms  in  both  classes 
are  configured  with  a  30  second  half-life,  which  is  also  the 
default  in  our  vanilla  experiment  and  in  public  Tor.  In  our 
diffserv  experiment,  we  isolate  the  new  scheduler  from  the 
LIRA  prototype:  all  clients  are  categorized  in  the  unpaid  class 
and  there  is  no  ticket  guessing  or  buying.  Eor  each  relay  in 
our  lira  experiments,  there  is  a  corresponding  client  who  uses 
that  relay’s  winners  to  receive  priority  for  all  of  its  downloads. 
Of  these  50  “paid”  clients,  we  configure  1  im  client,  47  web 
clients,  1  bulk  client,  and  1  p2p  client.  The  remaining  clients 
are  “unpaid”  and  will  only  receive  a  prioritized  circuit  by 
correctly  guessing  with  probability  p  =  0.01.  Each  prioritized 
circuit  may  be  used  for  /3  =  10  MiB  of  data  transfer,  after 
which  new  guesses  are  submitted. 

As  shown  by  the  cumulative  distributions  of  download 
times  in  Eigure  11,  the  new  scheduler  appears  to  give  slightly 
preferential  service  to  low  throughput  im  clients  and  slightly 
worse  to  high  throughput  p2p  clients.  The  scheduler  tends  to 
perform  slightly  worse  than  Tor’s  default  scheduler,  possibly 
because  our  prototype  implementation  has  not  been  optimized. 
Our  diffserv  experiment  provides  a  base  upon  which  LIRA 


may  be  compared.  The  fundamental  mechanism  provided  by 
the  scheduler  that  is  used  to  create  performance  incentives  is 
tunable  class  differentiation.  Eigure  11  shows  the  scheduler’s 
ability  in  this  regard,  as  paid  downloads  are  clearly  differenti¬ 
ated  from  unpaid  downloads.  Note  that  the  loss  in  performance 
for  paid  im  downloads  in  Eigure  1  la  is  an  artifact  of  the  small 
sample  (a  single  im  client)  and  high  latency  due  to  unfavorable 
placement  in  the  topology. 

New  Relay  Capacity.  Eigure  11  shows  performance  in  a 
network  where  only  the  existing  Tor  relays  receive  priority. 
We  now  explore  a  situation  where  several  existing  clients 
begin  routing  traffic  for  Tor.  We  consider  networks  where  5% 
and  15%  of  the  existing  client  base®  begin  running  a  relay, 
adding  a  total  of  25  and  75  relays  and  newly-paid  clients  to 
the  existing  sets  of  50.  Rationally,  each  new  relay  severely 
rate-limits  its  contribution  so  as  to  earn  only  enough  winning 
tickets  to  support  the  expected  throughput  requirements  of  its 
client  as  computed  from  our  vanilla  experiment.  This  is  a 
conservative  estimate.  Each  client  contributes  four  times  its 
expected  client  throughput  since  LIRA  will  prioritize  1/4  of 
a  relay’s  contributed  bytes  when  £  =  3.  Therefore,  rate-limits 
are  set  to  20  KiB/s  for  those  running  im  clients,  80  KiB/s  for 
those  running  web  clients,  340  KiB/s  for  those  running  bulk 
clients,  and  128  KiB/s  for  those  running  p2p  clients.  Note 
that  1/3  of  the  added  relays  are  exit  relays,  roughly  the  same 
proportion  as  in  the  current  Tor  network. 

The  rate-limiting  outlined  above  results  in  6.5%  and  17.1% 
total  additional  network  capacity,  and  represents  a  slightly 
pessimistic  approximation  of  expected  client  contributions.  To 
understand  both  extremes  of  the  range  of  possible  user  behav¬ 
iors,  we  configure  other  networks  where  the  same  15%  of  new 
relays  chosen  above  do  not  rate-limit  their  contributions.  In  the 
non-rate-limited  networks,  new  relay  bandwidth  is  sampled 
from  the  Net  Index  distribution  [46]  and  results  in  a  95.7% 
and  383.5%  increase  in  network  capacity.  Eigure  12  shows 

^Of  the  5%  of  clients  that  begin  running  relays,  we  select  1  im,  23  web,  1 
bulk,  and  1  p2p.  Of  the  15%,  we  select  2  im,  69  web,  2  bulk,  and  2  p2p. 


(b)  320  KiB  web  clients 


(c)  5MiB  bulk  clients  (d)  16  KiB  p2p  clients 

Fig.  1 1 ;  Client  download  time  distribution  in  vanilla  Tor,  when  using  our  proposed  scheduler,  and  after  adding  LIRA’S  design 
modifications.  LIRA  adequately  differentiates  performance  for  paying  clients  without  additional  capacity. 


the  result  of  additional  capacity  on  client  performance.  As 
expected  and  not  surprisingly,  the  added  capacity  results  in  a 
net  increase  in  overall  performance  over  LIRA  without  new 
relays,  even  under  our  rate-limiting  scenarios.  The  net  benefit 
to  the  network  increases  for  all  clients  types,  and  more  dra¬ 
matically  as  more  capacity  is  added.  Our  results  confirm  that 
LIRA  (using  the  proportional  throughput  scheduler)  enables 
performance  incentives  for  contributors. 

VI.  Related  Work 

Several  incentive  schemes  have  been  proposed  for  mix- 
nets  [49],  [50],  [51]  but  do  not  directly  apply  to  low-latency 
anonymous  communication  networks  or  Tor.  Incentive  designs 
for  Tor  include  PAR  [19],  a  scheme  where  relays  accept  real 
monetary  payments  from  clients  in  return  for  routing  service. 
PAR  separates  payments  into  anonymous  coins  paid  by  clients 
to  guard  relays,  and  more  efficient  identity-bound  coins  paid  to 
the  remaining  relays.  PAR  and  a  similar  micropayment  scheme 
called  XPAY  [20]  require  an  online  bank  to  participate  in  the 
routing  protocol  to  verify  that  the  coins  have  not  been  double- 


spent.  LIRA,  however,  is  much  more  scalable  as  it  does  not 
require  the  bank  to  be  involved  in  any  routing  transactions. 
LIRA  also  does  not  suffer  from  the  fundamental  trade-off 
between  double-spending  detection  and  accountability  that 
plagues  PAR  and  XPAY,  wherein  anonymity  inherently  de¬ 
creases  as  the  ability  to  detect  cheaters  improves. 

Ngan  et  al.  propose  a  lighter-weight  scheme  in  which 
the  fastest  7/8  relays  are  marked  with  a  “gold  star”  in  the 
public  Tor  directory  based  on  measurements  by  the  directory 
servers  [18].  These  relays  are  given  priority  as  they  build 
circuits  through  other  gold-star  relays,  and  enjoy  improved 
performance  because  only  fast  relays  receive  gold  stars.  Un¬ 
fortunately,  relay  anonymity  is  reduced  because  the  set  of 
potential  initiators  of  a  prioritized  circuit  (the  gold-star  relays) 
is  much  smaller  than  that  of  an  unprioritized  circuit  (any  active 
client).  LIRA  manages  the  small  anonymity  set  problem  by 
allowing  every  user  to  receive  priority  by  correctly  guessing 
a  winning  ticket. 

Jansen  et  al.  propose  BRAIDS  [21],  an  incentive  scheme 
that,  similarly  to  LIRA,  eliminates  the  double-spending  prob- 
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Fig.  12:  Client  download  time  distribution  as  clients  begin  to  run  relays.  Adding  additional  capacity  as  shown  results  in  a  net 
increase  in  performance  considering  both  paid  and  unpaid  clients. 


lem  by  using  relay-specific  “tickets”.  Each  relay  may  directly 
prevent  the  double  spending  of  its  tickets  without  needing 
to  contact  the  centralized  bank.  BRAIDS  aims  to  improve 
anonymity  for  relays  by  distributing  tickets  to  all  clients, 
using  existing  guard  nodes  as  proxies  for  distribution.  This 
strategy  limits  the  total  number  of  tickets  that  may  exist 
in  the  system  due  to  bank  resource  constraints  and  reduces 
payment  flexibility.  LIRA  is  more  efficient  in  this  regard  since 
it  must  only  manage  ticket  transactions  for  relays  providing 
service — a  much  smaller  set  than  that  of  all  clients.  BRAIDS 
also  differentiates  service  [33]  by  asking  clients  to  specify 
and  pay  for  the  desired  class  (“high  throughput”  or  “low 
latency”),  which  may  partition  clients  and  negatively  affect 
their  anonymity.  Conversely,  clients  do  not  choose  their  desired 
class  in  LIRA. 

As  an  alternative  to  using  e-cash  or  other  payment-based 
cryptographic  mechanisms  to  provide  incentives,  Moore  et  al. 
suggest  in  Tortoise  [9]  a  universal  rate  limit  of  Tor  clients 
and  an  exemption  from  such  throttling  for  relays  marked 
as  stable  and  fast  in  the  consensus.  Unfortunately,  this 


approach  suffers  from  anonymity  problems  similar  to  the  gold- 
star  approach  described  above:  the  anonymity  set  of  a  given 
circuit  is  limited  to  a  subset  of  relays,  and  the  timing  of 
relays’  priority  status  appearing  in  the  consensus  leaks  infor¬ 
mation  that  enables  an  intersection  attack  over  time.  LIRA, 
however,  provides  strong  anonymity  for  well-dehned  spending 
levels.  As  in  LIRA,  Tortoise  clients  may  multiplex  traffic  over 
multiple  guards  to  evade  throttling,  thereby  weakening  the 
incentives  provided  by  the  system. 

There  has  also  been  some  work  considering  the  behavior  of 
participants  in  an  anonymous-communication  network  from 
an  economic  perspective.  Acquisti  et  al.  [52]  describe  the 
costs  and  benefits  of  anonymity-network  users,  identify  the 
challenges  in  designing  systems  that  cope  with  selfishness, 
and  present  some  possibilities  for  solving  those  challenges. 
Humbert  et  al.  [53]  provide  an  analysis  of  using  a  scrip  system 
to  incentivize  selhsh  agents  in  a  cooperative  privacy-enhancing 
system  such  as  an  anonymity  network.  They  establish  the 
existence  of  a  Nash  equilibrium,  examine  its  social  welfare, 
and  show  how  to  manage  the  supply  of  scrip.  Future  study  of 


sociological  behaviors  in  LIRA  would  be  interesting  should 
the  system  be  deployed. 

VII.  Conclusion 

The  Tor  network  suffers  from  performance  problems  par¬ 
tially  caused  by  a  lack  of  relays  willing  to  altruistically 
volunteer  bandwidth.  This  paper  presented  LIRA,  a  novel 
incentive  scheme  that  increases  performance  for  those  who 
contribute  to  the  network  by  running  a  relay.  We  have  shown 
that  clients  who  choose  to  run  relays  enjoy  faster  downloads 
than  those  who  don’t,  due  to  a  novel  ticket  lottery  design  and 
a  scheduler  that  differentiates  service  for  winning  tickets. 

LIRA  provides  a  higher  degree  of  anonymity  than  previous 
proposals  while  eliminating  the  need  for  clients  to  contact  the 
bank  since,  with  tunable  probability,  clients  can  randomly  self¬ 
produce  winning  tickets. 

There  are  numerous  directions  for  future  work.  Among 
them  is  developing  a  better  understanding  of  the  economics 
of  anonymous  incentives  and  how  rational  users  might  be 
expected  to  behave  in  LIRA  or  a  similar  design.  Also  useful 
would  be  a  modified  incentive  structure  that  provides  non¬ 
linear  payoff  for  contributed  capacity  and  higher  payoff  for 
more  desirable  relays  such  as  bridges,  exits,  and  those  in 
more  diverse  geographic  locations.  A  distributed  bank  that 
functions  securely  within  Tor’s  trust  model  would  improve 
scalability.  Finally,  better  defenses  against  strategies  for  at¬ 
tempting  to  cheat  the  system  and  improved  protection  against 
long-term  anonymity  problems  associated  with  linking  paid 
high-throughput  users  would  not  only  benefit  LIRA,  but  any 
system  attempting  to  provide  anonymity-protected  incentives. 
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